home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-02-17 | 43.2 KB | 1,761 lines |
-
- $VER: SuperView_Ref_ENG.doc V10.1 (2.2.95)
-
- © 1994 by Andreas R. Kleinert. All rights reserved.
-
- - Feel free to translate this Doc-File into other languages. -
-
- Andreas R. Kleinert,
- Grube Hohe Grethe 23,
- D-57074 Siegen,
- Germany.
-
- Phone: +49-271-331859 (weekdays after 18.00h)
- +49-271-332147 (weekdays after 18.00h)
- EMail: Fido Andreas Kleinert 2:2457/435.10
- Usenet/InterNet Andreas_Kleinert@superview.ftn.sub.org
-
- If nothing else works, try one of these Fido-InterNet gateways:
-
- Andreas_Kleinert@p10.f435.n2457.z2.fido.sub.org (in Germany)
- Andreas_Kleinert@p10.f435.n2457.z2.fidonet.org (USA or other)
-
-
- Please note the version-dependencies :
-
- superview.library SVObjects SVDrivers SVOperators
-
- Version 1 - - -
- Version 2 Version 1 - -
- Version 3-8 Version 1,2 Version 1 -
- Version 9 Version 1,2 Version 1 Version 1
-
- Request at least : V2+ for SVObjects
- V3+ for SVDrivers
- V4+ for bug-fixed ClipBoard-Support
- with the supplied SVObjects
- V5+ for bug-fixed GfxBuffer-Functions
- V6+ for working GfxBuffer-Writing
- with the supplied SVObjects
- V7+ for adding/removing single SVObjects/SVDrivers
- V8+ for filetype recognition without loading
- V9+ for SVOperator functions
- V10+ added handling of "foreign" GfxBuffers
-
-
- Here is a listing of all currently available functions of the
- superview.library in an Autodoc-like style of description :
-
- SVL_AllocHandle ; since Version 1
- SVL_FreeHandle
- SVL_CloseDisplay
- SVL_FreeResources
- SVL_SuperView
- SVL_SuperWrite
- SVL_InitHandleAsDOS
- SVL_InitHandleAsClip
- SVL_SetWriteType
- SVL_SetWindowIDCMP
- SVL_SetWindowFlags
- SVL_SetScreenType
- SVL_GetWindowAddress
- SVL_GetScreenAddress
- SVL_GetErrorString
- SVL_SetWriteScreen
- SVL_SetWriteName
- SVL_FileInfoRequest
- ; no functions added in Version 2
- SVL_GetGlobalDriver ; since Version 3
- SVL_SetGlobalDriver
- SVL_ReadToGfxBuffer
- SVL_GetGfxBuffer
- SVL_SetGfxBuffer
- SVL_DisplayGfxBuffer
- ; no functions added in Version 4
- ; no functions added in Version 5
- SVL_GetSVObjectList ; since Version 6
- SVL_GetSVDriverList
- SVL_FreeSVObjectList
- SVL_FreeSVDriverList
- SVL_RemoveSVObject ; since Version 7
- SVL_RemoveSVDriver
- SVL_AddSVObject
- SVL_AddSVDriver
- SVL_GetFileType ; since Version 8
- SVL_DoOperation ; since Version 9
- SVL_GetSVOperatorList
- SVL_FreeSVOperatorList
- SVL_RemoveSVOperator
- SVL_AddSVOperator
- ; no functions added in Version 10
-
- -----------------------------------------------------------------------------
- Functions available since Version 1 - 2 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AllocHandle
-
- SYNOPSIS
-
- APTR SVL_AllocHandle(APTR future)
- D0 -$1e A1
-
- FUNCTION
-
- Allocates a handle for accessing a Graphic via SVObjects.
-
- INPUT(S)
-
- future - always NULL yet
-
- RESULT
-
- NULL or a pointer to a ready-to-use handle.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeResources, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeHandle
-
- SYNOPSIS
-
- VOID SVL_FreeHandle(APTR handle)
- D0 -$24 A1
-
- FUNCTION
-
- Stops showing, frees all Resources and delocates a Handle, which has
- been allocated with SVL_AllocHandle before.
-
-
- For programmers of SVObjects :
-
- Note, that this functions calls
-
- SVL_CloseDisplay(SVHandle);
- SVL_FreeResources(SVHandle);
-
- for internal SVObjects and
-
- SVO_FreeHandle(SVHandle->ah_SVHandle);
-
- CloseLibrary((APTR) SVObjectBase);
-
- for external SVObjects.
- So do not forget to do the SVO_CloseDisplay() and SVO_FreeResources()
- calls inside SVO_FreeHandle().
- Otherwise memory might be lost.
-
- INPUT(S)
-
- handle - a valid handle
-
- BUGS
-
- This function was buggy for external SVObjects (never closed, memory
- loss) upto V2.4.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeResources
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_CloseDisplay
-
- SYNOPSIS
-
- VOID SVL_CloseDisplay(APTR handle)
- D0 -$2a A1
-
- FUNCTION
-
- Stops showing the Graphic, indentified by the handle.
- The Display-Screen is closed, but no Resources are given free.
-
- INPUT(S)
-
- handle - a valid handle
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeResources, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeResources
-
- SYNOPSIS
-
- VOID SVL_FreeResources(APTR handle)
- D0 -$30 A1
-
- FUNCTION
-
- Frees all resources belonging to the specific Graphic,
- indentified by the handle, which are not needed to just show it.
- The Display will not be closed.
-
- Note, that SVL_FileInfoRequest() will no longer work, then
- ("No file loaded" or similar request appears).
-
- INPUT(S)
-
- handle - a valid handle
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SuperView
-
- SYNOPSIS
-
- ULONG SVL_SuperView(APTR handle, char *filename)
- D0 -$36 A1 A2
-
- FUNCTION
-
- Loads and shows the Graphic described by FileName.
- The handle is initialized and the fitting SVObject is opened
- and accessed for showing the Graphic.
-
- Showing can be stopped either via full delocation of the handle
- or via Closing the Display with SVL_CloseDisplay.
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle, SVL_CloseDisplay, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SuperWrite
-
- SYNOPSIS
-
- ULONG SVL_SuperWrite(APTR handle)
- D0 -$3c A1
-
- FUNCTION
-
- Before Version 3 a Graphic had to be loaded AND showed via
- SVL_SuperView : No separate reading and showing calls were done.
- For writing - that means : converting - a Graphic, you at first
- have to display, then to save it. Use the following order :
-
- (But check the "result" value AFTER EACH function call, like this
- has been done in the example SourceCodes ...)
-
- source_handle = SVL_AllocHandle(N);
- /* result = SVL_InitHandleAsDOS(source_handle, N); */ /* default */
- result = SVL_SetWindowIDCMP(source_handle,
- IDCMP_MOUSEBUTTONS | IDCMP_VANILLAKEY, N)))
- result = SVL_SetScreenType(source_handle, CUSTOMSCREEN, N)))
- result = SVL_SuperView(source_handle, source_filename)))
- result = SVL_GetScreenAddress(source_handle, &sv_screen, N)))
- result = SVL_GetWindowAddress(source_handle, &sv_window, N)))
-
- dest_handle = SVL_AllocHandle(N);
- /* result = SVL_InitHandleAsDOS(dest_handle, N); */ /* default */
- result = SVL_SetWriteType(dest_handle, dest_type, N)))
- result = SVL_SetWriteName(dest_handle, dest_filename, N)))
- result = SVL_SetWriteScreen(dest_handle, sv_screen, N)))
- result = SVL_SuperWrite(dest_handle);
- SVL_FreeHandle(dest_handle);
-
- SVL_FreeHandle(source_handle);
-
-
- Since Version 3 it is also possible to save the contents of
- SV_GfxBuffers, so that not necessarily a Screen has to be the
- source for writing to Disk/ClipBoard (or to whatever).
- Not all SVObjects may necessarily support this (return-code
- becomes SVERR_ACTION_NOT_SUPPORTED).
- But since Version 6 all of the supplied SVObjects (those which come
- with superview.library and contain Write-Support) allow this.
- So, if you request at least V6+, the likelihood will be with you ...
-
- All available values for dest_type can be found in the specific
- SVObject-List in SuperViewBase.
- The values WILL change with every re-initialization of
- superview.library, so update them with every new opening
- (read them from the SVObject-List inside SuperViewBase or use the
- new functions, which have been introduced with V6).
- Only ILBM.svobject and ACBM.svobject (and the internal Datatype-
- svobject, which cannot be used for saving, anyway) keep the same
- values for compatibility reasons, but since two of these are now
- external you might not be sure, if they are available
- (which means : actually in "LIBS:svobjects") or not ...
-
- INPUT(S)
-
- handle - a valid handle (used for Write Access)
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
-
-
- SVL_AllocHandle, SVL_FreeHandle
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_InitHandleAsDOS
-
- SYNOPSIS
-
- ULONG SVL_InitHandleAsDOS(APTR handle, APTR future)
- D0 -$42 A1 A2
-
- FUNCTION
-
- Initializes a Handle for AmigaDOS access, so that the given
- AmigaDOS FileNames are used.
- Another possibility is sometimes to initialize Handles
- for ClipBoard Access (depending on the specific SVObject,
- e.g. IFF-ILBM).
-
- INPUT(S)
-
- handle - a valid handle
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- During V2.4 upto V3.8 this was done automatically ALWAYS.
- This was fixed in V4.1
- See BUGS under SVL_InitHandleAsClip.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_InitHandleAsClip
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_InitHandleAsClip
-
- SYNOPSIS
-
- ULONG SVL_InitHandleAsClip(APTR handle, APTR future)
- D0 -$48 A1 A2
-
- FUNCTION
-
- Initializes a Handle for ClipBoard access, so that the (possibly)
- given AmigaDOS FileNames are ignored.
- The nearly always used possibility is to initialize Handles
- for AmigaDOS Access (supported by ALL SVObjects).
-
- INPUT(S)
-
- handle - a valid handle
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- From 2.4 to 3.8 this function-call was useless, since
- superview.library blocked all medias other than
- AKO_MEDIUM_DISK for external SVObjects :
- For reading calls, this resulted in a "file not found" message
- from superview.library, for writing calls, this resulted in an
- empty filename string, which caused the SVObject to reject the
- disk access (other accesses were not set correctly).
- This was fixed in 4.1, by using the SVO_SetAccessMode() function
- with the right parameters now and by using the "future" parameter
- of SVO_CheckFileType() - only when using other media than
- AKO_MEDIUM_DISK - as a pointer to an additional SVOCheckFileInfo
- structure now.
- This is 100% compatible, since superview.library has always set
- this value to NULL, so that older SVObjects will simply ignore
- this pointer and newer versions will only interpret it, if it's
- not NULL.
-
- SINCE
-
- ... version 1 of the superview.library. (request V4+)
-
- SEE ALSO
-
- SVL_InitHandleAsDOS
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteType
-
- SYNOPSIS
-
- ULONG SVL_SetWriteType(APTR handle, ULONG write_type, APTR future)
- D0 -$4e A1 A2 A3
-
- FUNCTION
-
- Sets the write_type for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- write_type - a valid temporary SubTypeCode from the SVObject-List
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWindowIDCMP
-
- SYNOPSIS
-
- ULONG SVL_SetWindowIDCMP(APTR handle, ULONG idcmp, APTR future)
- D0 -$54 A1 A2 A3
-
- FUNCTION
-
- Sets the default IDCMP-Flags for a SVL_SuperView() call.
- While displaying, the Address of the Window can be get via the
- SVL_GetWindowAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- idcmp - a valid number of IDCMP-Flags
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWindowFlags
-
- SYNOPSIS
-
- ULONG SVL_SetWindowFlags(APTR handle, ULONG flags, APTR future)
- D0 -$5a A1 A2 A3
-
- FUNCTION
-
- Sets the default Window-Flags for a SVL_SuperView() call.
- While displaying, the Address of the Window can be get via the
- SVL_GetWindowAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- flags - a valid number of Window-Flags
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetScreenType
-
- SYNOPSIS
-
- ULONG SVL_SetScreenType(APTR handle, ULONG type, APTR future)
- D0 -$60 A1 A2 A3
-
- FUNCTION
-
- Sets the default Screen-Type for a SVL_SuperView() call.
- While displaying, the Address of the Screen can be get via the
- SVL_GetScreenAddress() function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- type - a valid ScreenType value (e.g. CUSTOMSCREEN)
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperView
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetWindowAddress
-
- SYNOPSIS
-
- ULONG SVL_GetWindowAddress(APTR handle, struct Window **window,
- D0 -$66 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- While displaying, the Address of the DisplayWindow can be get
- via this function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- window - a valid address of a Window-Pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetScreenAddress
-
- SYNOPSIS
-
- ULONG SVL_GetScreenAddress(APTR handle, struct Screen **screen,
- D0 -$66 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- While displaying, the Address of the DisplayScreen can be get
- via this function.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- screen - a valid address of a Screen-Pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetErrorString
-
- SYNOPSIS
-
- char * SVL_GetErrorString(ULONG error_code)
- D0 -$72 A1
-
- FUNCTION
-
- Returns the Error Message for a specific Error Code, returned
- by any function of the superview.library.
-
- INPUT(S)
-
- error_code - any SVERR Error Code
-
- RESULT
-
- read-only pointer to a SVERR Error String
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- -
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteScreen
-
- SYNOPSIS
-
- ULONG SVL_SetWriteScreen(APTR handle, struct Screen *screen,
- D0 -$78 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- Sets the Source Screen for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- This will overwrite a previously done SVL_SetGfxBuffer() call.
-
- INPUT(S)
-
- handle - a valid handle
- screen - a valid pointer to an opened Screen
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetWriteName
-
- SYNOPSIS
-
- ULONG SVL_SetWriteName(APTR handle, ULONG write_name, APTR future)
- D0 -$7e A1 A2 A3
-
- FUNCTION
-
- Sets the write_name for a SVL_SuperWrite() call.
- See description there and example SourceCodes for more and
- detailed information.
-
- INPUT(S)
-
- handle - a valid handle
- write_name - a valid AmigaDOS FilePath and -Name description
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- SVL_SuperWrite
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FileInfoRequest
-
- SYNOPSIS
-
- ULONG SVL_FileInfoRequest(APTR handle, struct Window *window,
- D0 -$84 A1 A2
-
- APTR future)
- A3
-
- FUNCTION
-
- Pops up an Info-Requester with more or less detailed information
- on the currently loaded Graphic.
- A window pointer may be given to select the place to pop it up.
-
- Note, that this function will fail, if you already called
- SVL_FreeResources() (might result in a "No file loaded" message) !
-
- INPUT(S)
-
- handle - a valid handle
- window - a valid Window Pointer or NULL
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- None known, but :
- For non-internal SVObjects SVO_FileInfoRequest() is called, thus
- if this one is buggy, ...
-
- The Easy-Requester (or whatever else it is) will usually be attached
- to IntuitionBase->ActiveWindow, if window is NULL.
- This may cause problems sometimes, so always specify a WindowPtr,
- if possible !
-
- SINCE
-
- ... version 1 of the superview.library.
-
- SEE ALSO
-
- -
-
- -----------------------------------------------------------------------------
- Functions added with Version 3 - 5 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetGlobalDriver
-
- SYNOPSIS
-
- ULONG SVL_GetGlobalDriver(struct SVD_DriverNode **driver,
- D0 -$8a A1
-
- ULONG future)
- A2
-
- FUNCTION
-
- Gets the Global Default ScreenDriver (SVDriver) from the
- specific field of SuperViewBase.
-
- Always use this function. Do not access SuperViewBase directly !
-
- INPUT(S)
-
- driver - a pointer to a SVD_DriverNode pointer
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_SetGlobalDriver()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetGlobalDriver
-
- SYNOPSIS
-
- ULONG SVL_SetGlobalDriver(struct SVD_DriverNode *driver,
- D0 -$90 A1
-
- ULONG future)
- A2
-
- FUNCTION
-
- Sets a new Global Default ScreenDriver (SVDriver) in the
- specific field of SuperViewBase.
-
- Always use this function. Do not access SuperViewBase directly !
-
- INPUT(S)
-
- driver - a pointer to a SVD_DriverNode
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_GetGlobalDriver()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_ReadToGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_ReadToGfxBuffer(APTR handle, char *filename)
- D0 -$96 A1 A2
-
- FUNCTION
-
- Reads the graphic file - specified with filename - into
- a SV_GfxBuffer structure.
-
- Access to this structure can be managed via SVL_GetGfxBuffer().
-
- The combination SVL_ReadToGfxBuffer() and SVL_DisplayGfxBuffer()
- has the same effect as a call to SVL_SuperView().
- But note, that GfxBuffer-functions only work with Version 2
- SVObjects, while SVL_SuperView() also fits to Version 1 SVObjects.
- Internally, the result is the same, anyway.
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This call was broken from V3-4 !
-
- SINCE
-
- ... version 3 of the superview.library. (request V5+)
-
- SEE ALSO
-
- SVL_GetGfxBuffer(), SVL_DisplayGfxBuffer()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_GetGfxBuffer(APTR handle, struct SV_GfxBuffer **buffer,
- D0 -$9c A1 A2
-
- ULONG future)
- A3
-
-
- FUNCTION
-
- For READ accessing the SV_GfxBuffer structure, which has been
- created with SVL_ReadGfxBuffer() or SVL_DoOperation() before.
-
- Do not change, write to or free this structure by hand.
- Nevertheless you may create your own structures.
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a pointer to a valid SV_GfxBuffer pointer
- future - always NULL yet
-
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This call was broken from V3-4 !
-
- SINCE
-
- ... version 3 of the superview.library. (request V5+)
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_DisplayGfxBuffer()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_SetGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_SetGfxBuffer(APTR handle, struct SV_GfxBuffer *buffer,
- D0 -$a2 A1 A2
-
- ULONG future)
- A3
-
- FUNCTION
-
- This function initializes a WRITE handle with any SV_GfxBuffer.
-
- The SV_GfxBuffer will only be used for read-only purposes and
- is usually not be touched in any way (if it will be modified
- during the operation, the changes will be undone after completion).
-
- The buffer won't be delocated, when free'ing the given handle,
- so this is still the task of its owner, then.
-
- This will overwrite a previously done SVL_SetWriteScreen() call.
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a valid SV_GfxBuffer pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- WARNING
-
- Before V6 the documentation said under FUNCTION :
- "If also a valid Screen Pointer is supplied, the SV_GfxBuffer
- is ignored".
-
- There's no guarantee for that AND you never should supply
- TWO Sources for ONE Destination.
-
- GfxBuffer-Writing works since V6 with the supplied SVObjects
- and they do prefer GfxBuffers, NOT Screens.
- Screens have to be converted into GfxBuffers internally, before
- they can written, so GfxBuffers should take less memory ...
- Last not least : This function was broken upto V5, anyway.
-
- BUGS
-
- This call was broken from V3-5 !
-
- SINCE
-
- ... version 3 of the superview.library. (request V6+)
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_SuperWrite()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_DisplayGfxBuffer
-
- SYNOPSIS
-
- ULONG SVL_DisplayGfxBuffer(APTR handle, struct SV_GfxBuffer *buffer,
- D0 -$a8 A1 A2
-
- ULONG future)
- A3
-
-
- FUNCTION
-
- The combination SVL_ReadToGfxBuffer() and SVL_DisplayGfxBuffer()
- has the same effect as a call to SVL_SuperView().
- But note, that GfxBuffer-functions only work with Version 2
- SVObjects, while SVL_SuperView() also fits to Version 1 SVObjects.
- Internally, the result is the same, anyway.
-
- The difference is : Multiple displaying is possible
- (SVL_DisplayGfxBuffer(), SVL_CloseDisplay(), SVL_DisplayGfxBuffer(),
- ... and so on).
-
- The SV_GfxBuffer still has to be freed the way it has been
- allocated : - (self-created) : e.g. SVSUP_FreeGfxBuffer()
- - SVL_GetGfxBuffer() : SVL_FreeHandle()
- - SVL_DoOperation() : SVL_FreeHandle()
-
-
- INPUT(S)
-
- handle - a valid handle
- buffer - a valid SV_GfxBuffer pointer
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- WARNING
-
- Prior to V10 it was not possible, to pass any "foreign"
- pointers to SV_GfxBuffers. This means, "buffer" also had
- to be the same pointer as the one returned by SVL_GetGfxBuffer(),
- otherwise the library would have claimed about a missing
- SVObject-Handle (which wasn't there and therefore not able to
- manage the display operation in its property of beeing the
- owner of the GfxBuffer)
-
- As with V10, you'll be abled to pass ANY SV_GfxBuffer to this
- function to get it displayed (you should use a new handle for
- any additional buffer).
- This results in a SVDriver-dependent display operation
- (the only exeception are non-picture Datatypes - if enabled -
- which will always be displayed without using the SVDrivers,
- because BOOPSI is needed. Since this is not enabled by default,
- you may not mind, but anyway: To bypass this, you'd have to
- use another handle and pass the Datatypes' GfxBuffer to
- to it, so that e.g. only the first picture of an ANIM would
- be taken out and displayed. Test it.)
-
- SINCE
-
- ... version 3 of the superview.library.
-
- SEE ALSO
-
- SVL_ReadGfxBuffer(), SVL_SuperWrite()
-
- -----------------------------------------------------------------------------
- Functions added with Version 6 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetSVObjectList
-
- SYNOPSIS
-
- ULONG SVL_GetSVObjectList(struct SVObjectInfo **listhead)
- D0 -$ae A1
-
- FUNCTION
-
- Creates a simplified list of all SVObjects (SubTypes), which
- may be used for read-only purposes until it has been freed
- via SVL_FreeSVObjectList.
-
- INPUT(S)
-
- listhead - a pointer to a SVObjectInfo structure pointer
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- This functions was slightly buggy in V6 versions.
- The List was not chained right, so that only the last
- SubType of each SVObject was linked to the list and the rest
- went to Nirwana, so that there also was a (small) memory loss.
- This bug has been fixed in V7.
-
- SINCE
-
- ... version 6 of the superview.library. (request V7+)
-
- SEE ALSO
-
- SVL_FreeSVObjectList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetSVDriverList
-
- SYNOPSIS
-
- ULONG SVL_GetSVDriverList(struct SVDriverInfo **listhead)
- D0 -$b4 A1
-
- FUNCTION
-
- Creates a simplified list of all SVDrivers, which
- may be used for read-only purposes until it has been freed
- via SVL_FreeSVDriverList.
-
- INPUT(S)
-
- listhead - a pointer to a SVDriverInfo structure pointer
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeSVDriverList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeSVObjectList
-
- SYNOPSIS
-
- ULONG SVL_FreeSVObjectList(struct SVObjectInfo *listhead)
- D0 -$ba A1
-
- FUNCTION
-
- Frees a list returned by SVL_GetSVObjectList.
-
- Pass the List-Header, not an entry !
-
- INPUT(S)
-
- listhead - a pointer to a SVObjectInfo structure
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_GetSVObjectList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeSVDriverList
-
- SYNOPSIS
-
- ULONG SVL_FreeSVDriverList(struct SVDriverInfo *listhead)
- D0 -$c0 A1
-
- FUNCTION
-
- Frees a list returned by SVL_GetSVDriverList.
-
- Pass the List-Header, not an entry !
-
- INPUT(S)
-
- listhead - a pointer to a SVDriverInfo structure
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 6 of the superview.library.
-
- SEE ALSO
-
- SVL_GetSVDriverList
-
- -----------------------------------------------------------------------------
- Functions added with Version 7 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_RemoveSVObject
-
- SYNOPSIS
-
- ULONG SVL_RemoveSVObject(struct SVO_ObjectNode *svo_node)
- D0 -$c6 A1
-
- FUNCTION
-
- Removes an SVObject from the internal List of SVObjects and tries
- to remove it from memory.
-
- This does only work, if not more than one programm is accessing
- superview.library and the SVObject.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOBJECT-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- svo_node - a pointer to a SVO_ObjectNode structure
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVObject-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVObjects again
- (e.g. for Write-Operations).
-
- BUGS
-
- No bugs known yet.
- But this function operates "deep in the system", so that
- there may occur interferences in very special situations
- (but usuallly should not).
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_RemoveSVDriver
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_RemoveSVDriver
-
- SYNOPSIS
-
- ULONG SVL_RemoveSVDriver(struct SVD_DriverNode *svd_node)
- D0 -$cc A1
-
- FUNCTION
-
- Removes an SVDriver from the internal List of SVDrivers and tries
- to remove it from memory.
-
- This does only work, if not more than one programm is accessing
- superview.library and the SVDriver.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVDRIVER-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- svd_node - a pointer to a SVD_DriverNode structure
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVDriver-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVDrivers again
- (e.g. for displaying graphics).
-
- BUGS
-
- No bugs known yet.
- But this function operates "deep in the system", so that
- there may occur interferences in very special situations
- (but usuallly should not).
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_RemoveSVObject
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AddSVObject
-
- SYNOPSIS
-
- ULONG SVL_AddSVObject(UBYTE *name)
- D0 -$d2 A1
-
- FUNCTION
-
- Tries to open the specified SVObject (full AmigaDOS-Path) and
- attempts to add it to the internal Lists.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOBJECT-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- name - full AmigaDOS-Path of the SVObject to add to the lists
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVObject-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVObjects again
- (e.g. for Write-Operations).
-
- Secondly, it is not checked, whether the added Library is
- _really_ a SVObject.
- Adding other libraries may result in a damaged internal
- SVObject-List in superview.library.
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_AddSVDriver
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AddSVDriver
-
- SYNOPSIS
-
- ULONG SVL_AddSVDriver(UBYTE *name)
- D0 -$d8 A1
-
- FUNCTION
-
- Tries to open the specified SVDriver (full AmigaDOS-Path) and
- attempts to add it to the internal Lists.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVDRIVER-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- name - full AmigaDOS-Path of the SVDriver to add to the lists
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVDriver-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVDrivers again
- (e.g. for displaying graphics).
-
- Secondly, it is not checked, whether the added Library is
- _really_ a SVDriver.
- Adding other libraries may result in a damaged internal
- SVDriver-List in superview.library.
-
- SINCE
-
- ... version 7 of the superview.library.
-
- SEE ALSO
-
- SVL_AddSVObject
-
- -----------------------------------------------------------------------------
- Functions added with Version 8 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetFileType
-
- SYNOPSIS
-
- ULONG SVL_GetFileType(APTR handle, char *filename, ULONG *filetype)
- D0 -$de A1 A2 A3
-
- FUNCTION
-
- Finds out superview-specific FileType-Code
- (redefined with every re-initialization of the Library) or
- SV_FILE_TYPE_UNKNOWN (== NULL == FALSE).
-
- Use the following call for a simple check :
-
- handle = SVL_AllocHandle(N);
- sverr = SVL_GetFileType(handle, filename, &filetype);
- SVL_FreeHandle(handle);
-
- This handle should NOT be used for any further operations
- on the file (will be opened and checked twice but only
- closed once, etc).
- Initialization operations are allowed nevertheless
- (e.g. SVL_InitHandleAsClip() ).
-
- Note, that this function fills in FILETYPES, not SUBTYPES.
- For e.g. writing you must specify SUBTYPES
- (ILBM-0, ILBM-1 or GIF87, GIF89a).
-
- FILETYPES are only for short identification and do only
- specify the global file type (ILBM, GIF, PCX).
-
- INPUT(S)
-
- handle - a valid handle
- filename - a valid AmigaDOS FilePath and -Name
- filetype - pointer to ULONG for SV_FILETYPE-Value
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 8 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle(), SVL_FreeHandle()
-
- -----------------------------------------------------------------------------
- Functions added with Version 9-10 :
- -----------------------------------------------------------------------------
-
- NAME
- SVL_DoOperation
-
- SYNOPSIS
-
- ULONG SVL_DoOperation(APTR handle, struct SV_GfxBuffer *source,
- D0 -$e4 A1 A2
-
- struct SV_GfxBuffer **dest,
- A3
-
- struct SVOperatorNode *operator, APTR future);
- D2 D3
-
-
- FUNCTION
-
- handle = SVL_AllocHandle(N);
- sverr = SVL_DoOperation( ... );
- SVL_FreeHandle(handle);
-
- This function allows to do any available operations (via SVOperators)
- on a given SV_GfxBuffer.
-
- The Source buffer is not touched this way, but a new buffer will
- be allocated instead.
- The pointer of the new buffer is returned by writing it to a given
- pointer variable or may be examined by calling SVL_GetGfxBuffer()
- also.
-
- INPUT(S)
-
- handle - a valid handle
- source - a SV_GfxBuffer to be used as "source"
- dest - a pointer to a pointer for the "destination" SV_GfxBuffer
- operator - an SVOperator description, as found in the internal
- list of SuperViewBase
- future - always NULL yet
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- SINCE
-
- ... version 9 of the superview.library.
-
- SEE ALSO
-
- SVL_AllocHandle(), SVL_FreeHandle(), SVL_GetGfxBuffer()
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_GetSVOperatorList
-
- SYNOPSIS
-
- ULONG SVL_GetSVOperatorList(struct SVOperatorInfo **listhead)
- D0 -$ea A1
-
- FUNCTION
-
- Creates a simplified list of all SVOperators, which
- may be used for read-only purposes until it has been freed
- via SVL_FreeSVOperatorList.
-
- INPUT(S)
-
- listhead - a pointer to a SVOperatorInfo structure pointer
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 9 of the superview.library.
-
- SEE ALSO
-
- SVL_FreeSVOperatorList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_FreeSVOperatorList
-
- SYNOPSIS
-
- ULONG SVL_FreeSVOperatorList(struct SVOperatorInfo *listhead)
- D0 -$f0 A1
-
- FUNCTION
-
- Frees a list returned by SVL_GetSVOperatorList.
-
- Pass the List-Header, not an entry !
-
- INPUT(S)
-
- listhead - a pointer to a SVOperatorInfo structure
-
- RESULT
-
- NULL or an adequate SVERR-Errorcode.
-
- BUGS
-
- -
-
- SINCE
-
- ... version 9 of the superview.library.
-
- SEE ALSO
-
- SVL_GetSVOperatorList
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_RemoveSVOperator
-
- SYNOPSIS
-
- ULONG SVL_RemoveSVOperator(struct SVP_OperatorNode *svp_node)
- D0 -$f6 A1
-
- FUNCTION
-
- Removes an SVOperator from the internal List of SVOperators and
- tries to remove it from memory.
-
- This does only work, if not more than one programm is accessing
- superview.library and the SVOperator.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOPERATOR-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- svp_node - a pointer to a SVP_OperatorNode structure
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVOperator-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVOperators again.
-
- BUGS
-
- No bugs known yet.
- But this function operates "deep in the system", so that
- there may occur interferences in very special situations
- (but usuallly should not).
-
- SINCE
-
- ... version 9 of the superview.library.
-
- SEE ALSO
-
- SVL_RemoveSVOperator
-
- -----------------------------------------------------------------------------
-
- NAME
- SVL_AddSVOperator
-
- SYNOPSIS
-
- ULONG SVL_AddSVOperator(UBYTE *name)
- D0 -$fc A1
-
- FUNCTION
-
- Tries to open the specified SVOperator (full AmigaDOS-Path) and
- attempts to add it to the internal Lists.
-
- ***
- REMEMBER TO UPDATE YOUR PROGRAM'S INTERNAL SVOPERATOR-LISTS
- AFTER SUCH AN ACTION !
- ***
-
- INPUT(S)
-
- name - full AmigaDOS-Path of the SVObject to add to the lists
-
- RESULT
-
- boolean value
-
- WARNING
-
- This function invalidates the internal SVOperator-List of
- superview.library.
- Remember to update your personal copies of this list,
- before accessing any specific SVOperators again.
-
- Secondly, it is not checked, whether the added Library is
- _really_ a SVOperator.
- Adding other libraries may result in a damaged internal
- SVOperator-List in superview.library.
-
- SINCE
-
- ... version 9 of the superview.library.
-
- SEE ALSO
-
- SVL_AddSVOperator
-
- -----------------------------------------------------------------------------
-
-
-